Article de reference

W^X

W^X ( écriture ou exécution , prononcé W xor X ) est une politique de sécurité des systèmes d'exploitation et des frameworks logiciels . Elle assure la protection de l'espace ex...

W^X ( écriture ou exécution , prononcé W xor X ) est une politique de sécurité des systèmes d'exploitation et des frameworks logiciels . Elle assure la protection de l'espace exécutable en garantissant que chaque page mémoire (un bloc de taille fixe dans l'espace d'adressage virtuel d'un programme , c'est-à-dire l'organisation de la mémoire qu'il utilise) est soit accessible en écriture, soit exécutable , mais pas les deux. Sans cette protection, un programme peut écrire (sous forme de données « W ») des instructions CPU dans une zone mémoire destinée aux données, puis exécuter (sous forme d'instructions « X », ou lecture-exécution « RX ») ces instructions. Cela peut s'avérer dangereux si l'auteur de l'écriture en mémoire est malveillant.

Cette terminologie a été introduite pour la première fois en 2003 pour les systèmes de type Unix , mais elle est aujourd'hui également utilisée par certains systèmes multiplateformes (tels que .NET ). D'autres systèmes d'exploitation ont adopté des politiques similaires sous d'autres appellations (par exemple, DEP sous Windows).

Sur les noyaux de systèmes d'exploitation de type Unix, comme le noyau Linux ou XNU , ou ceux utilisés comme composants dans des systèmes d'exploitation plus vastes tels que FreeBSD , OpenBSD , Solaris et les services système UNIX de Z/OS , W^X est contrôlé par l' appel système mprotect . Son utilisation est relativement simple sur les architectures de processeurs prenant en charge une gestion fine des permissions de pages, telles que SPARC , x86-64 , PA-RISC , Alpha et ARM .

Le terme W^X a également été appliqué aux permissions d'écriture/exécution du système de fichiers afin d'atténuer les vulnérabilités d'écriture (notamment en mémoire) et la persistance des attaquants. L'application de restrictions sur les permissions de fichiers permet également de combler les lacunes de l'application de W^X dues aux fichiers mappés en mémoire. Interdire purement et simplement l'utilisation de code natif arbitraire peut également atténuer les vulnérabilités du noyau et du processeur non exposées par le code existant sur l'ordinateur. Une approche moins intrusive consiste à verrouiller un fichier pendant toute la durée de son mappage en mémoire exécutable, ce qui suffit à empêcher les contournements après inspection.

Compatibilité

Certains processeurs Intel 64 de première génération étaient dépourvus du bit NX requis pour W^X, mais celui-ci est apparu dans les puces ultérieures. Sur les processeurs plus limités, tels que l' Intel i386 , W^X nécessite l'utilisation de la limite du segment de code CS comme une « ligne de démarcation », un point dans l'espace d'adressage au-dessus duquel l'exécution est interdite et où se trouvent les données, et en dessous duquel elle est autorisée et où se trouvent les pages exécutables. Ce schéma a été utilisé dans Exec Shield .

Des modifications de l'éditeur de liens sont généralement nécessaires pour séparer les données du code (comme les trampolines requis par l'éditeur de liens et les fonctions d'exécution de la bibliothèque ). L'option permettant ce mélange est généralement activée sur les systèmes de type Unix execstack

W^X peut également poser un problème mineur pour la compilation à la volée (JIT) , qui consiste pour un interpréteur à générer du code machine à la volée, puis à l'exécuter. La solution simple, utilisée par la plupart des développeurs, y compris Firefox par le passé , consiste à rendre la page exécutable une fois le code machine généré par l'interpréteur, SELinux contrôle ces opérations la randomisation de l'espace d'adressage permettrait de placer les deux pages dans le même processus en toute sécurité. Les partisans de la première approche estiment que la seconde n'est sûre que si les deux pages sont attribuées à deux processus distincts, et que la communication interprocessus serait plus coûteuse qu'un simple appel à `wp_exit()`

Histoire

W^X a été implémenté pour la première fois dans OpenBSD 3.3, sorti en mai 2003. En 2004, Microsoft a introduit une fonctionnalité similaire appelée DEP ( Data Execution Prevention ) dans Windows XP. Des fonctionnalités similaires sont disponibles pour d'autres systèmes d'exploitation, notamment les correctifs PaX et Exec Shield pour Linux , ainsi que l'implémentation de PaX dans NetBSD . Dans Red Hat Enterprise Linux (et automatiquement dans CentOS ) version 5, ou à partir du noyau Linux 2.6.18-8, SELinux a reçu les Bien que W^X (ou DEP) n'ait protégé que les programmes utilisateur pendant la majeure partie de son existence, Microsoft l'a étendu au noyau Windows sur les architectures x86 et ARM en 2012. Fin 2014 et début 2015, W^X a été ajouté au noyau OpenBSD sur l'architecture AMD64. Début 2016, W^X était entièrement implémenté sur le noyau AMD64 de NetBSD et partiellement sur le noyau i386.

Les ordinateurs macOS équipés de processeurs Apple Silicon appliquent la politique W^X à tous les programmes. Les Mac équipés de processeurs Intel appliquent cette politique uniquement aux programmes utilisant le mode d'exécution renforcé du système d'exploitation.

De Firefox 46 en 2016 à Firefox 116 en 2023, la machine virtuelle de Firefox pour JavaScript a implémenté la politique W^X. Cette politique a ensuite été abandonnée sur certaines plateformes pour des raisons de performance, mais est restée en vigueur sur d'autres qui l'appliquent à tous les programmes.

.NET utilise W^X à partir de .NET 6.0 en 2021.

Plus d articles de Worldlex Wiki

Revenez a l index pour explorer davantage de pages sur l histoire, la science, la culture, la geographie et la societe en francais.

Explorer l index